ADFA-4128 (8/11): quickbuild:core — session orchestration - #1720

…ploy-throw containment

Stale cancel flag: the Prebuilding stop latches proxyAppBuildCancelIssued with no teardown to clear it, so a later "Restart session" skipped the Gradle cancel -> clear the flag whenever an effect launches new session work (StartProvisioning / StartProxyAppPrebuild / RunProxyAppRebuild); covered by "a session started after a prebuild-stop still gets its Gradle build cancelled on restart".

Unguarded provision-success tail: retention clear, generation adoption and watcher.start ran unguarded on a scope with no CoroutineExceptionHandler -> wrap the tail in the same try/catch -> ProvisioningFailed boundary the rebuild arm already uses; covered by "a watcher-start throw in provisioning's success tail fails the session instead of escaping".

Collector-killing deploy throw: resendRetainedPayload called deploy.deploy() bare inside the init-launched reconnect collector, so one throw disabled catch-up for the process -> contain non-cancellation throwables as a failed re-send (return false, fall back to the catch-up build); covered by "a throwing re-send is contained - catch-up falls back now and stays alive for later reconnects".

Co-Authored-By: Claude Fable 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Kj9YeCDHGp9DU8LPtfWJ7W

- F1720-1 draw the eight transitions the authoritative diagram omitted

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01FstXxJ5cwWPcvmhZ9vJgJ7

…med fallbacks

Applies the fix-now items from the 2026-08-31 review triage.

Foreground policy (Bryan, 2026-08-31): the proxy app comes forward only for
a user's Quick Build tap, and then exactly when enough building has happened
to carry their changes.
- A successful rebaseline with no user ask outstanding reconnects in the
  background instead of relaunching the app (runner gains a
  userAskOutstanding gate).
- A tap during a save-triggered rebaseline is recorded
  (Provisioning.userInitiated) and honoured when the rebuild lands, instead
  of being dropped.
- A rebaseline ask is exempt from the 10 s deferred-ask expiry - the bound
  stays for non-rebaseline asks (foregroundAskAwaitsRebaseline).
- A variant-switch reprovision dispatches userInitiated = false
  (SessionRestartAndReprovisionRequested is now a data class carrying the
  flag); the menu/dialog restart stays explicit true.

Other fixes:
- A FIRST proxy app rebuild that loses the Gradle slot parks recoverable
  (awaitingRetry) instead of dying to Idle with a failure banner.
- A Degraded tap only respawns the daemon when restartFailed; while the
  DaemonDied respawn is in flight it acks without racing a second respawn
  (respawns never bump the daemon epoch, so they would race, not supersede).
- Messageless throws surface named messages (new
  QuickBuildMessage.ProvisioningFailedUnexpectedly, or RebuildFailed for
  rebuild paths) instead of a raw exception class name; the class and stack
  stay in the error log.
- ProxyAppInfo.launcherProxyClass gives the launch target one home shared by
  restart deploy, rebuild relaunch and the foreground switch.
- domain/session README state diagram redrawn from the post-fix reducer,
  adding the transitions the review found missing.

RESTACK NOTE for qb-11: QuickBuildMessage gains ProvisioningFailedUnexpectedly,
so the app-module mapper QuickBuildMessages.resolve (exhaustive when) will
fail to compile until it adds the new case - the loud break that mapper's
design intends.

Tests: red-first (12 predicted failures observed), then green -
:quickbuild:core:testV8DebugUnitTest, 1128 tests pass. Two obsolete expiry
tests deleted (chained-landing expiry, fresh-clock-after-expiry): both pin
the removed rebaseline expiry.

Also: plain-language pass over the comments added by these fixes

Also: honour a deferred rebaseline ask once, not twice (code review 09-01, important 2). ProxyAppRebuildResult.Succeeded.answeredUserAsk tells the manager the runner's relaunch already answered the ask, and it clears the deferred ask before the landing dispatches, so Ready does not launch the app a second time for the same tap. Seven launch-count assertions go from two launches to one.

Co-Authored-By: Claude Fable 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01STCsdMzx9daNBcqMN424Ci

Akash's 2 September round on the session state machine.

- A tap landing while the rebaseline is already running no longer launches the
  proxy app twice. The rebuild relaunches the reinstalled app itself for an
  outstanding ask; ProvisioningSucceeded now says so, and the reducer skips the
  switch it would otherwise emit for the same tap. Pinned by a test that fails
  without the guard.
  #1720 (comment)
- answeredUserAsk is true only when the relaunch actually succeeded, so a
  refused start leaves the ask outstanding for the landing to answer instead of
  dropping it.
  #1720 (comment)
- The daemon death listener reads the epoch on the reaper thread and drops a
  death that the session's own intentional transition caused. This does not
  close the duplicate-DaemonDied finding it was filed under; see below.
  #1720 (comment)
- A build that deployed nothing reports the generation the app is running, not
  the newest one allocated. A failed deploy leaves the allocator ahead of the
  app, and reporting it advanced the session's deploy tally past a generation
  the app never ran, forcing a catch-up build on every reconnect.
  #1720 (comment)
- The tap's history write is skipped once the project has recorded a Quick
  Build, so a blocking preference commit no longer runs on the single-threaded
  session dispatcher on every tap. That gives hasUsedQuickBuild its only
  caller, and the constructor doc no longer claims the prebuild gates on it.
  #1720 (comment)
  #1720 (comment)
- Both remaining messageless-throwable sites fall back to named copy rather
  than the exception class name, which reaches the status surface verbatim.
  #1720 (comment)
  #1720 (comment)

Not fixed here: the duplicate DaemonDied itself. One death is reported twice -
by the death listener and by the build that was riding the daemon - and telling
the second report from a fresh death of the respawned daemon needs a daemon
instance identity on the event. The only place that identity exists is the
daemon client, which belongs to the PR below this one, so the fix wants its own
change rather than a cross-PR edit in a review pass. A flag for "a respawn is
in flight" was tried and rejected: it also swallows the death of a daemon that
dies inside its own start, which an existing test pins.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_017o3nPrBbGi2XYkMUGavG2A

Answers review threads 3926554702, 3926554709, 3926554719, 3926555512 and the
duplicate daemon-death thread on PR #1720.

- teardown cancels the orchestrator's in-flight build before shutting the daemon
  down, so no compile is left running against a daemon that is going away and
  writing into a scratch tree the teardown is about to remove
- the session scope carries a CoroutineExceptionHandler; five effect launches
  call straight into the orchestrator or the daemon with no boundary of their own
- a build variant selected during the provisioning window is re-checked once the
  session goes live, instead of being dropped with nothing to correct it later
- the warm-compile early return reports the generation the app is running, not
  the allocator's, which could be ahead of it after a build that never deployed
- one physical daemon death has two reporters that cannot see each other; a
  second report from the OTHER reporter is now recognised as the same death,
  which stopped a successful respawn from being refused

Each is pinned by a test that fails without it.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_017o3nPrBbGi2XYkMUGavG2A

…ate diagram

Answers review thread 3926554735 on PR #1720. The diagram showed the edge as
unconditional; the reducer only emits SwitchToProxyApp when the provision was
user-initiated and the ask has not already been answered.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_017o3nPrBbGi2XYkMUGavG2A

…its English sentence

DaemonProcessClient writes English into DaemonReply.Failed.message and the
provisioner passed it to the user verbatim as a Literal, which the message
type documents as never a sentence written in this module. A new
DaemonStartFailed case carries the reason as detail, the way
DaemonRestartFailed does; the host renders it inside localized copy.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_017o3nPrBbGi2XYkMUGavG2A

The session dispatcher is one thread and concurrency.md's rule for it is that
nothing on it may block. Four call sites broke that rule: session start read
watchedRoots() and watchedFiles() for the filter and again for the watcher, and
each of those re-walks the project root; the annotation baseline walks and reads
every source file; and the executor scans all sources on every build.

Each of the four now hops with withContext to an injected IO dispatcher.
Session start also reads the two watch accessors inside ONE hop, so it does two
walks off-thread where it used to do four on it.

The dispatcher is injected rather than hard-coded because a real Dispatchers.IO
escapes runTest's virtual time - with the hop hard-coded, 142 of the session
manager's 182 tests went red. It threads manager -> factory -> executor, and the
manager's tests put it on their own scheduler.

Tests record which thread did the work. The session-start one ties the
assertion to the walk itself, through a project root that reports the thread
that listed it; the other two count hops on a recording dispatcher, which is
zero without the fix.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_017o3nPrBbGi2XYkMUGavG2A

…d brings a daemon up

A failed respawn left lastDeathReporter set to WATCHER, so the save that is meant to
recover from Degraded(restartFailed) built against the dead daemon, reported that death
from the build side, and had it dropped as a re-report - leaving the session in Building
with nothing but "Restart session" to move it. The proxy app rebuild had the same gap
from the other direction: it starts a daemon of its own while the parked respawn ends
Superseded, so the new daemon's first death was dropped whenever a build saw it first.

Every place a daemon comes up or is given up on now resets the reporter, as the
provision path already did.

Review: #1720 (comment)

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XkGof8cLt23LkxZ8MKzin2

liveGeneration() fell back to the allocator before the first deploy and its KDoc said
the two agree by construction. They do not: the allocator is the project's persisted
counter, adoptAtLeast is a max, and an unstamped (0) baseline - what a host older than
the stamping change installs - never moves it. With a counter above the stamp, the
provision's warm compile reported the allocator, the executor latched it, and the next
deploy-nothing build advanced the deploy tally to a generation the app never received,
forcing a catch-up build on every reconnect.

The factory now hands each executor the stamp the installed baseline boots at, from the
provision outcome and from the rebuild result, so the fallback is never taken for a
session executor. The KDoc says what the fallback is now for.

Review: #1720 (comment)

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XkGof8cLt23LkxZ8MKzin2

…ssion dispatcher

The head commit hopped the layout's tree walks but left the asset packaging behind, two
statements from the hop it added: packageAssets and the forced route's packageAllAssets
walk the asset roots and read every file into a zip on the one thread whose rule is that
nothing on it may block, and proxyAppArtifactsIntact stats the whole classpath there on
every external build. No wrong result; the cost was latency on the session work queued
behind them - a watcher batch, an orchestrator event, a daemon-death report.

The scratch tree's sweep and remove are the remaining two sites; they become suspend and
hop inside QuickBuildScratch on the provisioning PR below this one, and the call sites
here follow when the stack is rebased onto it.

Review: #1720 (comment)

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XkGof8cLt23LkxZ8MKzin2

…ile diagnostics

The provisioning branch made FileGenerationStore, QuickBuildScratch and
GenerationTracker suspend and hop to an injected dispatcher, and put a
successful compile's warnings on CompileOutput.diagnostics. This branch's
callers adapt: ProxyAppBuildRunner opens the tracker through
GenerationTracker.open, the teardown's scratch.remove runs inside the suspend
scope, and the manager test gives its scratch tree the test scheduler so the
disk hops stay in virtual time (the real Dispatchers.IO default left 160 tests
asserting before the provision's freeSpaceShortfall came back).

The warnings now travel the same path a failed build's errors do:
BuildOutcome.Success.diagnostics, set by the executor from the compile step,
onto SessionEvent.BuildSucceeded, QuickBuildSessionState.Deployed and
QuickBuildStatus.UpToDate, all defaulting to empty so every existing
construction stands. The app branch lists them in the Build Output under the
reload line.

Review threads:
#1719 (comment)
#1719 (comment)
#1720 (comment)

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XkGof8cLt23LkxZ8MKzin2

…are()

A daemon start that fails or rejects the configure, or a session assembly
throw, left the tree prepare() had just made; a user retrying a failing
provision accumulated one tree per attempt until the next manager start
swept them. The runner now removes it on those paths, after the daemon is
down. The superseded paths keep the tree: the restart in flight reuses it
and the manager's teardown owns its removal. (PR #1719 review thread.)

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XkGof8cLt23LkxZ8MKzin2

…e cancel path

LiveReloadOrchestrator.onCancelRequested -> ADFA-5456, QuickBuildSessionManager -> ADFA-5501.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XkGof8cLt23LkxZ8MKzin2

adoptBaseline moved every ProxyAppInfo-derived piece except the watch set.
The filter and watcher were built once from the pre-rebuild layout, and
AndroidProjectWatcher fixes its inotify set and poll list at construction,
so a rebaseline that added a module (a :lib in settings.gradle.kts) kept
watching the old roots and every edit under lib/src produced no batch, no
build and no message for the rest of the session. The roots, files, filter
and watcher now travel as one SessionWatch; the factory derives it again on
every rebuild and hands back the current one when the set is unchanged, so
the common rebaseline keeps its running watcher. A replacement starts before
the old one stops, because the poll primes its fingerprints on start and an
edit in a stop-then-start gap would be taken as baseline.

Answers #1720 (comment)

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Y6rFuAJin4QFFwwzUTFZ1K

… session down

The Provisioning stop arm only knew about a first provision, but a rebaseline
parks there too with a BUILDING tone that says tapping stops it. The stop
then emitted TeardownSession: watcher stopped, daemon shut down, scratch tree
removed, and the next tap paid a cold provision - harder than the rebuild's
own failure and slot-busy arms, which park at Invalidated with everything
kept. A rebaseline stop now cancels only the Gradle build; its cancelled
outcome comes back as ProxyAppRebuildFailed and parks for retry, and the
manager skips Gradle's account of the cancellation, since the user already
saw BUILD_CANCELLED.

Answers #1720 (comment)

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Y6rFuAJin4QFFwwzUTFZ1K

…weep join, cancellation, no ask expiry

The daemon controller now owns which death reports are news (noteDeath) and
forgets a death once any start has returned or a shutdown ran, replacing five
hand-placed resets in the manager - the one a future path forgets was the
Building-for-good bug. provision() joins the stale-tree sweep instead of
trusting launch order, since sweep() hops to IO and a prepare could overtake
it. The history write and the timeline metric rethrow CancellationException.
A deferred foreground ask no longer expires after 10 s: the user tapped, and
a Gradle build on a phone takes as long as it takes. The per-batch watcher
debug line is guarded. A respawn that hits a rejected configuration reports
the daemon's first diagnostic.

Answers:
#1720 (comment)
#1720 (comment)
#1720 (comment)
#1720 (comment)
#1720 (comment)
#1720 (comment)

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Y6rFuAJin4QFFwwzUTFZ1K

…p's uid after a rebuild

ProxyAppRebuildOutcome.Success now carries the uid PackageManager reports for
the reinstalled app, and the runner re-opens the registry on it before the
daemon restarts. The uid survives an in-place reinstall, but not an app that
was removed in between - and the host service trusts callers by uid alone.

Answers:
#1720 (comment)

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Y6rFuAJin4QFFwwzUTFZ1K

The three BuildSucceeded edges name the SwitchToProxyApp effect a user-initiated
build carries, and Idle gets its own SessionRestartRequested self-edge.

Answers:
#1720 (comment)
#1720 (comment)

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Y6rFuAJin4QFFwwzUTFZ1K

ktlint import order for the DeathReporter import added in the round 5 fixes.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Y6rFuAJin4QFFwwzUTFZ1K

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Y6rFuAJin4QFFwwzUTFZ1K